The memory layout of a native data structure is not guaranteed to be stable or backwards compatible. In theory, even if the developer uses the same compiler binary with the same source code, the compiler is still allowed to use a different memory layout of native data structures based on non-deterministic optimizations.
While multi-memories enable fast access to the stable memory, the developer still needs to ensure that data stored in the stable memory is stable and backwards compatible.
This would be a great bounty for someone to pursue while exploring these patterns at the library level. Pipelineify already handles a lot of this queuing action, and it would likely need to use some of the libraries that would help with managing input output queues.
I remember reading about throughput limitations of BTC transactions, but can’t find it. Something like one transaction per block per subnet. Does anyone know the actual number and whether there is ongoing work to increase it?
To clarify: the limit you point to is the current throughput of tECDSA signatures per second that a subnet can produce (you need those in order to submit BTC transactions so of course the limit on those sort of implies a limit on the BTC transactions themselves).
AFAIK, the current implementation of tECDSA is not super optimized, so I would expect that this limit can be increased eventually. Likely there is going to be some limit on what a single subnet can do (the protocol is quite complex) but there is always the possibility to allow more subnets to sign using tECDSA which means we can “scale out” the throughput of these operations on the IC as whole.
Discussion on data structures vs. databases on the IC
Discussion on cycle limits
Update on ic-stable-memory which allows dynamic key/value lengths and a certified map compatible with certified assets protocol.
If you watch the recording and have thoughts please feel free to add them here.
We have also a request to move the working group from Thursdays at 5:30 pm CET (GMT+1) to Wednesdays at 6:30 pm CET (GMT+1). Are there any objections to that? Note that we’d still use the cadance of every 3rd Wednesday of a month.
For the WG tomorrow I’ll be presenting some benchmark results comparing the ic-stable-structures and ic-stable-memory libraries, as well as sharing some tips on efficiently using stable memory. This should be useful for those of you planning to store significant data in stable memory.