If the central problem is that people could buy short-term votes if a neuron market emerges (and I am not sure that is actually the central problem), perhaps a solution lies in eliminating for a specified duration the NNS voting power of neurons whose controllers change, without restricting the rewards that accrue from votes? I don’t know how feasible this would be, but it seems easier than trying to prevent a neuron marketplace from emerging. Advances that are currently halted because they would enable a neuron market as a side effect can then be rolled out quickly.
6 Likes
I like this idea too. A limitation on voting power for a time period could be an effective deterrent.
I’m not sure if it’s possible to identify canister controlled neurons or what it would take to enable that identification (which was my original question to Lara). It it becomes possible, then there could be many potential solutions to the security risks and value reduction that could occur from the formation of neuron markets.
2 Likes
I think it would be really hard to somehow detect if the real ownership of a neuron has changed if canisters can control neurons. We could of course detect that the controller of a canister that controls a neuron has changed, but there are many other ways to change ownership of a neuron. Eg the canister may be blackholed but its state changes to change ownership, or the controller of the canister is another canister and ownership may change there.
8 Likes
Indeed, there will be ways found to get around the vote pause regulation. My question is: what is the systemic threat that arises out of a neuron market? If sufficient obstacles can be placed through NNS votes and code tweaks to deter such a systemic attack, without changing anything for stakers uninterested in selling neurons, that should be good enough even if there are leaks in the defences. Sometimes, searching for a silver bullet is futile or even counterproductive. In this case, the counterproductive part would involve pausing an important advance in order to stave off undesirable consequences. Of course, if Dfinity engineers have an inkling of a potential silver bullet, that’s great, I’m sure the community will happily wait.
2 Likes
Vote pause regulation sounds pretty reasonable, but penalizing neuron transfer incentivizes people to trade neurons using offline key exchange, tECDSA, or other undetectable means.
3 Likes
I think the standard…or best practice…to put in place here is that for a non-self authenticating principal to be able to hold a neuron it needs to be an open-sourced canister with a clear purpose as to why it needs to own a neuron(maybe also blackholed or controlled by a known and open governance mechanism). Maybe a whitelist similar to ‘named neurons’ would be helpful here where the NNS has the ability to add/remove you from the whitelist. If you’re off the list you lose your voting power. Just thinking out loud here.
2 Likes
Ngl I’m not a fan of this approach 
Would it be too much to ask for us to just let things play out and respond with some control measure if/when the need arises?
Looking at the NNS today there is 460M+ VP.
250M+ tokens are not staked and in circulation
In order for a canister-controlled neuron market to pose a threat it would need the ability to pass a non-governance proposal type. Right now Dfinity has that locked down with almost 100% of the followers votes.
So this new market, with no existing stake, would need to be managed by an attacker that has absorbed the entirety of the circulating supply and staked it for 8 years in order to have a chance at getting majority approval.
Is my napkin math wrong? Do we think this is a realistic threat anytime in the next 5-10 years?
With the initial token launch, all neurons were set up to follow DFINITY and reap voting rewards on day one. We were all told that we must vote in order to be entitled to voting rewards. No promises were made that the rules wouldn’t change. It was clearly documented that the NNS is a mutable governance system. Yet a lot of community resistance to changes to the NNS are rooted in arguments like “we were promised” or “this change isn’t what I signed up for” or “you are stealing from non voters”.
I anticipate neuron marketplaces and canister controlled neurons will have the same community sentiment if we take a wait and see approach and try to implement solutions at a later date. They don’t exist today, but if they are allowed to exist without clear rules and attempts to prevent security issues then people will start complaining if and when changes to the rules become necessary. It seems preferable to address it now since this was a security threat identified by DFINITY before genesis.
2 Likes
I think we are conflating the threats. If you are referring to the discussions early on from @jwiegley my understanding is that he was talking about enabling the transfer of existing neurons. This change would not allow that to happen so it’s a different risk. Hopefully we hear some updated feedback from DFINITY regarding the risk of this specific proposal.
3 Likes
Hi all,
we had some discussions in DFINITY regarding whether NNS neurons should be controllable by canisters.
Our current take is that we should not allow canisters to control NNS neurons as we should not risk the creation of neuron markets. One main concern about having services that offer “staked tokens” and hold huge NNS neurons is that these services would have a very large, aggregated voting power in the NNS which may thus centralize the voting power.
Some more detailed concerns / answers to some questions in this thread:
- “The Same is already possible with ECDSA / http”: This is true. But rather than making neuron markets even simpler, we currently think that we should rather try to prevent these cases as well by adding additional authentication means to a neuron. One idea would be to add to a neuron not only a controller but also an additional key or means of authentication that could not easily be done with ECDSA.
- “Couldn’t we just allow some canisters to control neurons, e.g., DAOs”. First it is not straightforward how an “allowed” canister would be defined. As some of you mentioned it is conceivable to work with whitelists etc. However, what should be allowed wasms? For example, it might first seem that it is valid to allow SNSs to control NNS neurons, as SNSs use code that has been approved by the NNS. However, an SNS could easily be used to actually create a neuron market, e.g., by the SNS token basically working as “wrapped NNS neurons”.
Next steps:
- As mentioned, rather than allowing all kinds of canister controllers, we plan to further look into how to prevent canister controllers by ECDSA + http. Initial ideas are discussed that include an additional key/protocol to access neuron functionality that could not be easily provided by a canister.
- We think that a lot of use cases why community members asked for this feature might also be solvable by other means. Notably, for implementing “known neurons” that can be registered in NNS governance for others to follow them on proposal decisions are often realized by a group of people managing this one known neuron. Instead of implementing this in a canister, this can already be realized by a special type of proposal type “manage neuron” that allows a selected group of neurons to manipulate one neuron. Moreover, more elaborate following-functions implemented in a canister can be achieved by adding a canister as a neuron’s hot key rather than the controller.
To enable the community to effectively use these existing tools, we plan to work on documentation on how these can be set up.
We will follow up once we have this additional documentation or more insights on the design of the new additions!
6 Likes
Thanks for this feedback on this topic Lara. It provides a lot of clarity on current DFINITY thinking, which is greatly appreciated.
Speaking of Manage Neuron features…
I am still very interested in using the Manage Neuron proposal type from within the NNS dApp for the Synapse neuron. It means also needing to be able to submit private proposals that only Followees of the Mange Neuron topic for our neuron can see and vote. I plan to transfer management of the Synapse neuron to our full group of voting members, but these Manage Neuron features need to be easier than command line. We need it built into the NNS dApp. I’m hopeful that this will be a priority for implementation.
As discussed with Bjoern T previously, I will also need to remove the II controller of the Synapse neuron after neuron management has been configured to follow our voting members. He explained a way that it can be done, but it would be preferred and appreciated if it can be publicly verifiable.
4 Likes
Please please please add this back into the NNS dapp!!!
3 Likes
Thanks for the update @lara. I respect DFINITY’s position on this even if I don’t agree with it. We will continue with our plan to use tECDSA for now.
2 Likes
When making the NNS Proposal Dapp I became very familiar with Axon. It’s a beautifully executed project that’s surprisingly full-featured and sadly under appreciated: GitHub - FloorLamp/axon: Neuron management canister
I think development has stopped on it (for over a year now), but it’s still functional and can solve most of your pain points out-of-the-box. I bet you could even have Synapse revive the project a bit to build any additional features you’d need, since that would only require a few tweaks and be a fantastic resource for the ecosystem!
Basically a canister can only control a few manage neuron commands (vote, follow, make proposal) by being added as a hot key for that Neuron. Since the hot key canister can make the neuron submit proposals, it has the ability to relay a manage neuron command to another neuron, using a manage neuron proposal. If the another neuron is delegated to follow manage neuron proposals from the relay neuron which has the canister as a hot key, then this means the canister can now control every Manage Neuron command (full control).
So yeah, while a canister can’t take full control of a neuron directly, it can do so as long as it sets up a proxy neuron for relaying proposals to a delegated neuron.
3 Likes
Am I correct in my understanding that a hotkey isn’t allowed to spawn maturity and disburse ICP?
It can spawn maturity but cannot disburse. I use if for ICDevs for a couple of people who have ‘dedicated’ their neurons to ICDevs. They still own the neuron but every couple of weeks I can spawn 1 ICP to go into the treasury. You have to hack the UI(put a breakpoint in the js code) to get it all set up, but it works if you can get it set up.
1 Like
Just a quick reminder that we have a bounty open at IC devs to fork Axon. I’d love to use it for the dev board and to make it easy for folks to make our neuron vote a-la-Synapse. Bounty - ICDevs.org Generic DAO - Axon Fork
3 Likes
Thanks Austin. I’m trying to think through the flow here. I’d rather not go against the foundation if I can make the hotkey method work.
Is your hotkey controlled by a canister or does someone at ICDevs have to log into the NNS app or use Quill to manage the hotkey neuron?
When you spawn a neuron from the hotkey neuron does control of the spawned neuron automatically get transferred to the ICDevs controller or can you direct the ownership of that spawned neuron?
To clarify a bit; If my canister has hotkey control of a neuron, then directs it to spawn a new neuron, how do I tell the new neuron to disburse if I can’t control that neuron because I’m a canister?
2 Likes
Someone who manages a neruon(manage neuron topic) can spawn a neuron to whatever controller they specify. If you also add that as a hot key stuff shows up in the NNS.
I think I messed up…it isn’t hotkey that can spawn…it is managed neuron that can spawn. When I had this set up through axon I had the axon added as the manage neuron and then I had to do a manage neuron of a neuron. It was very meta and could have been easier to pull off.
2 Likes
I see. I’ll have to try to brush up on the manage neuron approach. It sounds like someone other than the canister could still be in control of the neuron but I may be misunderstanding.
At the end of the day all I want is a way to control a neuron’s voting and distribution of rewards through a blackholed canister. And I don’t want that neuron to be controlled by anything other than that canister. I honestly never cared about the ability to transfer the neuron.
1 Like