Is it technically feasible for IC to run 100x faster?

I’m noticing huge latency when I just try to merge my rewards from staking. It can take several seconds for the tokens to merge.

Is it technically feasible that one day the IC will run 100x faster? It needs to be about that speed for it to truly be “internet grade.” Or is there something intrinsic to the consensus protocol (e.g. Chain Key Cryptography) that will have to be changed to achieve that level of performance?

If it is technically feasible, is this something being actively worked on? If it’s being worked on, is there a sense of timeline when we might see performance improvements?

Or, ultimately, is this just a server allocation issue? That we could horizontally scale and everything would run faster?

1 Like

It depends, you’re probably referring to time to finality, which is limited by speed of light. Nodes need to talk to each other to reach consensus, the higher the node count in a subnet the higher the time to finality. This Reddit thread might interest you: https://www.reddit.com/r/dfinity/comments/u83yh4/is_there_any_future_plan_to_increase_the_number/

That being said there are also other factors that determine IC’s performance: canister performance and how many canister a subnet has are some of them.

Afaik single canisters can process 200 transaction per second, so if a subnet were used by a single huge canister it wouldn’t be able to process more than that, if a subnet has tens/hundreds of canister then it would perform better.

2 Likes

Well, 100x faster would mean an update in 20ms. If anyone manages to cram in lots of messages for consensus between servers on physically different continents (~150ms average RTT), and get the result in 20ms that would mean we’ve solved some other fundamental physics problems, and we’re on our way to the Singularity or something :slight_smile:

Think of it this way: the consensus mechanism needs to exchange data between several servers that are physically far away from each other. Imagine laying a fiber between each other. Your best theoretical RTT between all of them, with several rounds of messages per consensus round add up pretty quickly. The ~1-2 seconds updates are really not that big of a deal even if you compare it with web2 web apps speeds. Sure, it won’t do FPS gaming, but that’s kinda not in scope…

2 Likes

Theoretically we could make a layer 2 that works faster right?

1 Like

To me, the 1-2 second updates are a huge deal.

I can’t even vaguely imagine a consumer grade app I use with 1-2 second delays between database actions.

1 Like

It really depends on the kind of application you’re building, but I somewhat agree and that’s why I think blockchain singularity is a pipedream.

2 Likes

That’s why you need to change your mindset from database actions to the Actor Model. Once you do this shift and it “clicks” for you, you’ll see that you can model most traditional user flows and mask the 1 second delay with spinning things that the user is already accustomed to.

As a matter of fact, I can barely remember web2 apps that deal with 3’rd party APIs and don’t take 1-2 seconds to “validate” something or the other. Hell, most pages under Cloudflare regularly hop balls on your screen, depending if you’re using a VPN or a residential IP…

Again, it all boils down to what you need to achieve, but for most things, 1-2 seconds per update is workable in a rather pleasant UX.

3 Likes

Hop on DSCVR or TAGGR and play around for a bit. They feel pretty much like reddit / twitter. With how many filters and microservices both run, posting some content can absolutely take 1-2 seconds (at least from you pressing send to some other person being able to view it on the web site - i.e. not a browser gimmick). It takes “classic” platforms 1-2 seconds to take a user message, pass it through the chain of validators, automated content id, automated spam filters, etc. and then showing it live. It’s 100% comparable with dscvr & taggr.

Don’t take my word for it, join those two apps, play around. You’ll be surprised that this is all on chain!

Yes, I’m expecting at some point there will be IC rollups that just focus on execution and not consensus and batch/settle transactions on IC data availability subnets

2 Likes

Yeah, DSCVR in particular is impressive.

So then maybe my question needs to be, “Why is NNS so damn slow?”

I have no idea about the internal workings of it, but I think a lot comes from the additional security requirements: You REALLY don’t want to display a wrong account id where someone may transfer a lot of ICP into. Therefore most calls that could be queries in many cases are actually run as update calls, so that the answer is correct and approved by consensus. OTOH, if DSCVR shows a wrong like count, what’s the worst that can happen? So it’s fine for them to use query calls, which are actually answered in the desired speed.

5 Likes

you need to design around it latency isn’t a new issue. goes all the way back to pong.

I think most web2 apps also take O(seconds) to commit state to their databases, but they probably mask that latency using optimistic updates, delayed replication, as well as other tricks to boost UX.

The IC is still a couple orders of magnitude slower than such a process would imply. But you are right - the responsiveness we’re accustomed to is partly a fiction. The big difference with web3 is that the fiction needs to be created in frontend code as the slowdown is inseparably aggregated. You can do tricks in a web2 backend to pretend it has communicated with deeper layers when it hasn’t, but any client prediction must actually be done on the client if the entire backend is on-chain.

3 Likes

In a web3 app does the entire backend always need to be on-chain?

Depends on your precise definition of web3. I think the purist mindset is defeated by the necessity of oracles.

1 Like