Canister groups

Developers
,
1

One problem that arises in the context of subnet splitting is that of collocation of canisters. The concept of canister groups should help. Some details are below.

Problem

Subnetwork collocation of canisters (henceforth, collocation) offers important advantages to canisters/dapps:

i) collocated canisters benefit from fast intercanister communication that does not go through consensus (within the cycles limit of a round). In turn, collocation enables multi-canister architectures which can take advantage of parallel execution of canisters & fast messages.

ii) canisters collocated on verified subnetworks can use intercanister query calls (ICQC): the current implementation is a PoC which is limited to canisters that are collocated. A feature which had been recently prioritized aims to offer ICQC to general subnets.

Canister migration between subnets (as envisioned, for example, by subnet splitting) may break the collocation assumption, an assumption which based on the above may be factored into dapps architecture.

This is an issue for subnet splitting and in general for moving canisters between subnetworks. Moving sets of canisters between subnetworks (per whatever load balancing policy we may use) may break the collocation assumption since we have no mechanism in place for the IC to learn which dapps/sets of canisters rely on collocation.

Canister groups
The notion of canister groups should help to solve this problem is. This concept would allow a dapp developer to designate (programatically) that a certain set of canisters form a group.
The IC would need to provide system support for group management and ensure that canisters in a group are permanently collocated (even if various forms of load balancing would require some canisters to move between subnetworks.)

Proposed design
The current design can be found in this document. Feedback, in particular on its limitations, would be highly appreciated.

14 Likes
2

Given the recent Composite Queries proposal, roadmap scheduled subnet-splitting feature, and hardware limitations on subnet sizes, I figured this feature should be getting significantly more attention that it has so far!

Tagging a few people building multi-canister applications to hopefully go in and comment in Bogwar’s Canister Groups design document with any questions or feedback you may have.

@lastmjs @skilesare @jzxchiang @hpeebles @bob11 @saikatdas0790 @yrgg @Gabriel @paulyoung @quint

7 Likes
3

Thanks for the heads up…super important feature here!

4

I’m assuming neither canister migration nor subnet splitting (mentioned by OP) has been implemented yet—hence this proposal. Is that accurate?

5

Sounds like a useful idea, I’m just troubled that we keep having to add cognitive overload to developers. This is yet another concept that we must incorporate into the design of our apps. I hope we can continue to move toward some of the original visions Dom shared of having a drastically simplified stack with superior developer experience to centralized clouds.

I understand that the complexities of scaling are causing these concepts to be introduced, just sad that some of the original vision I felt promised just isn’t reality and may never be.

4 Likes
6

Do you have any links to instances of Dom talking about that? I watched a lot of his old interviews but never heard about specifics.
Imho it was and is a pipedream, building a decentralized network which is scalable enough to host 90% of software is already a huge feat on its own, abstracting away all the complexities of scaling on top of it seems quite unrealistic.

7

Speaking very generally I wouldn’t say that this is unrealistic, moreso that if you want to abstract away complexity that generally means the platform or sdk/library is making more decisions for the developer. This then means the more high-level the software, the more opinionated it is - which could be a plus for some developers and a big minus for others.

Going too high level too soon also runs the risk of fixing the direction of the platform or certain patterns (i.e. with respect to scaling) before other use cases and paths have been explored, and could introduce backwards incompatible changes (one-way doors).

I think DFINITY is generally doing a good job of listening to developers’ pain points and learning from their experiences and examples in trying to accomplish something. I’m sure other developers will build tools and sdks that will abstract away different parts of application design until best practices emerge, but it’s all about striking the right balance.

In my opinion, it’s important that many of these “best-practices” aren’t fixed into the platform and developers aren’t “locked-in”, at least until there’s a critical mass of developers pushing DFINITY/the IC in that direction or the change is absolutely necessary (i.e. security vulnerability).

2 Likes
8

That’s correct @jzxchiang – there is a design for subnet splitting. An important question there is how to ensure that subnet splitting doesn’t break any collocation assumptions made by a multi-canister architecture. Organizing canisters in groups, explicitly, would allow the IC to ensure that breaking collocation does not happen.

9

Thanks for the discussion so far. Following some of the questions, I’ve added a small section describing the challenges that would be raised by supporting fully dynamic groups.

I think @lastmjs @Zane and @icme discuss (above) perhaps the most important question around canister groups – the added cognitive load on developers, which certainly something of serious concern.

One question which may help understand the scope/usability of this feature better is:

Given that same-subnet canister communication is much faster than inter-subnet communication
do developers actually rely on collocation at all? Perhaps this is not the case so in some sense canister groups are moot.

Of course, the answer may be a bit more difficult if this reliance is implicit (all canisters created by a canister will be collocated so collocation simply happens without the dev being aware/caring about it).
How big of a surprise would it be if canister creation would simply create a canister on a less loaded subnet rather than on the same subnet?

1 Like
10

I was just reading this page on the SNS:

https://internetcomputer.org/docs/current/developer-docs/integrations/sns/sns-intro/

Towards the end it has a warning about SNS canisters running out of cycles. Then it says:

In the future, cycles management will be simplified in a new feature that allows canister groups, where cycles can be managed across different canisters.

Is that referring to this same feature? If so I think this is the first time I’ve seen any mention of cycles management as it relates to canister groups.

1 Like
11

Cycles sharing is not part of this feature, but we do envision that at some point you could, optionally, allow canisters in the group to share a cycles account.

Is cycles management a pain point?

1 Like
12

Is it possible to make calls between canisters in a group support atomicity?

Canister groups that support atomicity will bring convenience to engineering. For example, developers can separate access routing, business logic and data storage in different canisters, easily implementing an MVC-like paradigm. This will bring convenience to large-scale application development.

1 Like
13

Hi @bitbruce

The issue of atomicity is certainly interesting and important, but it is largely independent of the concept of canister groups discussed here.