NNS Feature Request: Batch Manage Neuron Requests

Developers
1

Hey all, Currently the NNS API has a manage neuron command, it’s type in Motoko looks like so:

manage_neuron : shared ManageNeuronRequest -> async ManageNeuronResponse;

With the manage neuron request looking like:

  public type ManageNeuronRequest = {
    id : ?NeuronId;
    command : ?ManageNeuronCommandRequest;
    neuron_id_or_subaccount : ?NeuronIdOrSubaccount;
  };

The feature request is to add a new endpoint (or adapt the current endpoint - up to the team) so that it takes in an array of requests and returns an array of results like so:

batch_manage_neuron : shared [ManageNeuronRequest] -> async [ManageNeuronResponse];

This would allow users and canisters to batch manage neuron requests in a single call, in our systems we allow something like this for our vectors, and I thought something like this would be incredibly useful on the NNS level.

From looking at the NNS code, all the manage neuron commands are sync and return appropriate errors, It should not be all or nothing, it should just return what failed and what was a success as it works in the current system.

There are lot of benefits if this was added. You can start providing pro-user type of UI’s and update all your neurons in one go (Instead of manually updating your neurons one by one). Also canisters providing neuron management services with many neurons and liquid staking protocols with buckets of neurons can operate far more efficiently - updating all of their neurons in one call - when operating in an async environment batch calls are very useful, it also frees up network load on both canisters.

Open to thoughts and feedback.

@lara @jasonzhu @bjoernek

1 Like
2

Hi @dfxjesse ,

From looking at the NNS code, all the manage neuron commands are sync and return appropriate errors

Actually, if I understand correctly what you are referring to, many of the manage neuron commands are async and require inter-canister calls to the ledger canister. E.g., claim, dissolve, split, disburse, merge etc all require checking ledger accounts or updating the ledger with the changes.
Therefore I think this would not be quite that easy.

Moreover, without having thought super long about it, I wonder if this could be a problem wrt resources - say if someone sent a huge request then one single person could keep governance busy for very long. While now everyone can just access one neuron at a time.

I wonder if there are any pressing use cases that need this. If this is the case, it would be interesting to learn more details about what exactly this case tries to achieve. This would maybe allow to come up with a more specific solution.

1 Like
3

Thanks Lara. You’re right, there are a few async (inter-canister calls) ones in there and when I original looked I was looking at disburse maturity and a couple of others - that don’t have inter-canister calls. So I was thinking it wouldn’t be as resource intensive and would be useful to batch it across a few neurons.

In general here, I am trying to figure ways to make the NNS API more adaptable to canister controlled neurons, with many neurons across different users - as that’s the use case I’m dealing with. Something like batch calls would be useful (but looks like it wouldn’t be as straight forward as I thought).

1 Like