Alright, a couple of weeks in, it is time for the first update to the Cycles Token (XTC) canister.
This update adds improvements to transaction history storage for the Cycles Token (XTC) canister, shifting from a linear history that lives in the main canister, to auto-scalable multi-canister architecture.
History Archive — Scalability Upgrade ⛰️
Right now we use the main Cycles Token (XTC) canister with a 4GB memory limit to store transaction history, 4GB isn’t a lot and at some point, it will become a bottleneck that will block us from storing a large number of transactions.
DFINITY has plans to change canisters to 128 GB in the future. Still, the timeline on that is not set, and in reality, it would just push the scalability issue to a later time. Better to resolve it now!
How did the architecture improve to solve this? 👷
We solved this problem by expanding the history into external canister architecture outside of the main XTC token canister.
The main canister continues to register transactions, but when it reaches a certain storage threshold (10k events) it automatically creates an archive of the history canister and stores/writes the old transactions there. Each Archive canister can hold up to around 100k events, which the main canister will fill up in 10k increments.
How do we handle the continuous scaling of archives? ⚙️
When the first archive canister (Archive 0) is topped with transactions (about 100k), the main XTC Token canister will create a new archive canister (Archive 1), and will continue to flash old transactions in 10k batches until it’s completely filled.
When a new archive canister is created, the flash/archiving process from the Main XTC Token canister will point to that new canister; and that new archive itself will be interlinked with the previous canister (and forth!).
That way, when a user tries to read the history from the Cycles Token (XTC) main canister, the query will automatically go through the main canister’s history, and then move on to the latest archive, and then to the one after that, and so on… Until it finds the required information.
Each canister is capable of routing the call to the next older canister as seen in the graph, this is a speedy process and would take seconds to go through.
We first approached this build using Motoko. But, due to the lack of memory management functionality in the garbage collection of the compiler, we found it more costly to develop. We used Rust instead, to be more specific and economical in the operations XTC performs.
Wrapping it up 👋
What’s next for XTC? We will be working on more stability and autonomy updates to the Cycles Token (XTC) canister, and start exploring alternate products that can complement XTC!
XTC has also been integrated into Plug recently! So you can now hold a balance, manage it, and send it across the browser wallet extension.
Join our discord to stay up-to-date with this news, chat with the team, and share what you’re building on XTC.
