Forum Internet Computer Developer Forum

Jacc1027: If I understand correctly you’re saying I can monitor and top up from the same dashboard? How this works is you log in, send icp to your wallet. Than you set spending limit from what backend can pull icp for topping up canisters. Than you go to Canister tab, there you got 2 options, 1. add canister where you added CycleGuard as co controller. This option is little dangerous, unless you own CycleGuard app yourself. 2. Safe option is --add-status-viewer xvk27-biaaa-aaaak-qzg5a-cai , this makes sure CG can read your cycle balance without app being able to change or delete your canisters. Canister tab will top up canisters when your set balance drops, example: canister has 2.2T, you set top up at 2T, and top up amount 1T, time interval where it checks and triggers if needed, usual 1d, if dont consume much, than 7d. If you go to Support Canisters, there you cant see cycle balance, can add any canister. Example, it you know your app consumes 1T cycles a month, you can put interval and 0.5 ICP per month (will add 14d and 30d later), i might put option it to calculate, so can pick cycle amount instead. If all goes well, app can be bought and owned by everyone for theyr personal canisters. After some time i will blackhole CG, so it will be safe to add it as controller and people dont need to worry about trust.

I wouldn’t be able to do something till like early November. Been working a lot on my own stuff, then also helping some companies get their stuff built up here on ICP.

Henn91: should add or This sounds great. I’m currently topping up two cans by manually checking balances, then going to my NNS wallet. If I understand correctly you’re saying I can monitor and top up from the same dashboard? Do I preload a third tank, and from that tank top up the two canisters ?

Those examples don’t really prove much yet. .near and .sui showing up on ICANNWiki just means someone publicly disclosed applications for those strings - it doesn’t mean NEAR did. Just look into Link Freedom Group (the ‘.near’ applicant, and you’ll see exactly what I mean). There are companies that apply for large portfolios of TLDs as a business strategy, so some of these could simply be domain/registry speculation rather than “official” protocol applications. Until ICANN publishes the full applicant list on 7 October, the absence of .icp isn’t meaningful either. We just don’t know yet

You don’t have to use anything I create, @Afre . But the fact that you keep showing up to comment on it is pretty funny. If you’re really that uninterested, why are you spending so much time talking about it? Maybe focus on your own projects instead of worrying about mine.

I maintain these repos : https://github.com/dragginzgame/canic https://github.com/dragginzgame/icydb https://github.com/dragginzgame/ic-query/ https://github.com/dragginzgame/ic-memory/ https://github.com/dragginzgame/ic-testkit/ https://github.com/dragginzgame/ic-timers/ https://github.com/dragginzgame/ic-blob-storage/ and work on a game : https://miner.toko.app/

I’ve seriously got 24 x 15TB Micron U.2 SSDs for sale if anybody’s interested. Worth a shot! I accept ICP and OpenChat.

Some relevant resources: youtube video article on storage roadmap article on storage layer In principle, the two limiting factors are how well we can even handle (hashing, checkpointing, etc) large states, and how much disk we use. For most of the lifetime of the IC, the handling was the actual bottleneck, and a lot of of work was necessary to get to the current limit of 2TiB. The links above go into details of these things, like the introduction of log-structured merge trees (LSMT). At this point, the disk use starts to become relevant, but mainly in a worst-case sense. For example, the files on disk for a checkpoint might be larger than the state size due to how we handle overlay files, and there might be multiple checkpoints on disk at any point, as required by the consensus algorithm. In practice however, we don’t use much more disk than the subnet size. We do want to keep enough disk space for the worst case though, because running out of disk might have very bad consequences for the subnet. We do plan to improve these things very soon. That should help at the very least to allow larger states on small engine disks. It will also help to increase the 2TiB mainnet limit as well, but there we also need to improve the handling of large states on top of the pure disk space calculations.

Yes there are VM’s for CE only (mainnet has only full spec capacity nodes, not part of them) but a node is a node if they are able to run Guest OS just like any other node, so in a 4 node config you could still run somewhat limited canisters. There was a thread that I can’t find anymore trying different ways to implement blob storage and using the excess capacity was mentioned.

Interesting question, I checked out some things quickly, thought the answer was the RAID, but it’s not. RAID 0 (being used) is striping: it spreads data across all five drives for speed. It doesn’t mirror or keep a backup copy, so most of the 32tb are available. The storage system needs additional space for: Checkpoints: older certified versions of the state must remain available while newer ones are created. State changes: the IC stores changed memory pages in additional files and periodically merges them. Old and new files can coexist during that process. Recovery and synchronization: checkpoints let restarted or replacement nodes catch up safely. Dfinity’s April 2025 storage roadmap distinguishes two steps: 1 → 2 TiB State synchronization speed and occasional hashing of the entire state needed testing. Beyond 2 TiB Retained old states and storage files could fill the physical disks under worst-case workloads . Reducing that overhead involves performance tradeoffs and protocol changes. One reason for having a lot of SSDs with RAID0 is to get more speed, lower latency, better UX. Looks like security & availability is another one, where you model it to handle worst-case workloads. You can’t make that very optimistic, or something can make the whole subnet go down. The roadmap points out software upgrades can improve it a bit

ZackDS: Looking at the cloud engine offerings the minimal Nano nodes have 100 GB specified and even the bare metal nodes only have 4 TB . Fun fact On another topic Are you sure those figures aren’t only indicative of what is accessible to the Cloud Engine users? I’m asking about the specs of the nodes. I think I’ve seen somewhere that the same node could be used in several Cloud Engines at the same time (which actually could be an answer to my question)

Without looking into it further, my guess is that it needs it for blockchain consensus. SSD writes and retrieves data too slow to be able to be used for updating the blockchain.