Building a Super dApp together on the Internet Computer

Today, I’d like to present a new approach to developing applications on the Internet Computer.
This vision tackles key ecosystem issues and, if done right, could completely redefine Web3 and create the foundation for a new economic era. The following article contains a high level description of the vision.

I’m opening this topic to anyone interested in discussing or challenging this vision. The article assumes technical possibilities, mainly the ability to place internal actors within our canisters.
While I don’t see any fundamental obstacles that would make this vision impossible to realize, I understand that a lot work is needed to make this real, and many questions need to be answered.

Let’s talk!

11 Likes

It is easier (and much more efficient) to implement on IC core level, by creating “sub-sub-nets” or “tightly connected” canisters that would use regular await, but work at speed of one canister (with await* instead).

1 Like

Yes, that approach is possible, provided the developer experience remains consistent with what is described in the article. However, I’m curious about how users would ‘own’ this sub-sub-net. It’s not just about facilitating easy communication between canisters; user ownership is a central aspect of this new paradigm.

A user will just own individual canisters, because they will be installed for him by canister installers.

BTW, it is useful to create a “canister manager” software, just like Linux package managers.

BTW, Seb, are you sure we need an additional speed-up to subnets (sub-subnets)? Aren’t subnets already fast?

After a few more conversations. I believe it doesn’t matter whether we use a single canister or multiple canisters as a group. What we need is:

  • All canisters must be owned by the user.
  • The system should provide a coherent and trusted computational environment. Inter-canister calls within this group should not require consensus or suffer from trust issues associated with calling other canisters.
  • From an external perspective, the group should appear as a single, unique actor that can be called and interacted with.
  • A cohesive building experience with what building a canister looks like today.

My original idea was to have canisters within a canister, but that’s just another way to approach it.

2 Likes

Inter-canister calls within this group should not require consensus

Already, several inter-canister calls in a single subnet are almost as fast as a single call. So, in a sense, inter-canister calls on a single subnet don’t require consensus.

or suffer from trust issues associated with calling other canisters.

You mean the issue with infinitely long not answering to a call that prevents a canister to be reinstalled? That should be solved on core IC level. It should not be our task to solve this.

From an external perspective, the group should appear as a single, unique actor that can be called and interacted with.

Why? Give an example.

The main issue here is that as the memory grows(or rather the size of the params of the call grows) you take a bit of a hit because the memory across actors is not shared. If you want to process something of any significant size the canisters have to copy the memory to the new canister. A single actor solution would be able to just reference the existing values in memory.

For small payloads this should be negligible, but if you want to process files or something like that it may not be as fast or give you as much processing per round as you would like.

It is possible to introduce shared memory areas. Not sure if it will speed-up a lot, however, because memory copying is already fast.

It could have the interface like:

stable var sh = [];
...
shareMemoryToActor(sh, anotherActor)

(not clear, how to implement it on WASM level, however; maybe the API should be tuned to ease implementing it in WASM).

However, I feel that your focus on performance is wrong. I propose to focus first on functionality. Otherwise, it is what since Donald Knuth is called preliminary optimization.

I doubt that it’s worth to hack the core for this apparently minor performance improvement. If I were a member of DFINITY council, I would be now unsure whether to vote for or against this performance feature, because it would increased complexity of the system, for an unclear advantage of a possibly minor speedup.

1 Like