The batched endpoint will return an array of results indicated if each send was successful or not. Providing a batch endpoint helps with the scalability of canisters that interact with the cycles ledger (or any ledger) when there are spikes in transaction requests.
As a use case, I would like to in a single request, send 100 SendArgs to the cycles ledger asking 100 different ledger accounts to transfer cycles to a specific canister. I would like to receive responses for each of the 100 transfer attempts indicating if they were successful or if they failed. In this case, I am trusting the result response from the cycles ledger that the cycles were successfully sent/transferred to a canister, and I don’t need to confirm after the fact that the cycles were actually sent.
This is not the same as a transactional update (where one would expect all messages or succeed, or would fail if one of the messages does not succeed)
Here’s my reasoning for providing a batch endpoint:
- Canisters have output queue limitations, so batching requests helps improve throughput to the cycles ledger. Canister Output Message Queue Limits, and IC Management Canister Throttling Limits - #2 by paulyoung
- Every outgoing request and outstanding call context requires a memory reservation, which is one of the reasons that the Scalable Messaging Model is being implemented. Providing a batch endpoint on a ledger reduces the number of outstanding calls at a single time (i.e. alternatively making parallel requests to the cycles ledger), which frees up this memory and increases the scalability of the subnet.