Thanks for creating this forum thread and I enjoyed reading the proposed solution.
I have been building https://rakeoff.io/, which is probably one of the main alternative staking applications on ICP outside of the NNS. From the beginning, I wanted to have a canister controlled neuron for Rakeoff, but the self-authenticated principal restriction stopped me.
A few months ago I seen it was possible with ECDSA and HTTP outcalls so I decided to focus my efforts on building a canister in Motoko that controls a neuron - those efforts were successful and this neuron is owned and controlled by a Motoko canister: Neuron: 15836007478619123946 - ICP Dashboard.
So, having wrote a lot of custom code and built a canister to control a neuron in Motoko I wanted share my experience and thoughts.
Creating a canister controlled neuron proved to be very laborious - mostly due to the whole thing just being a workaround for the self-authenticated principal restriction, It resulted in hundreds if not thousands more lines of code (deep dives into cbor, candid and DER encodings and many other things). However, If I can figure it out - I think many others can too and that left me with the main question - why is this restriction here? The current self-authenticated principal restriction should really be renamed “A principal derived from a user or a dev who has spent many hours debugging and figuring out how to create a canister that pretends to be a user”. I’ll coin it - “dev-authenticated principal”
The path I see forward is either approving this proposal and opening the doors in a safe and well thought out way (shoutout to @bjoernek & @bjoern ) or creating a different proposal to stop the current ECDSA and HTTP outcall neurons. I think the second option is not a viable option as DAOs like OpenChat already have large neurons staked via this way and it would probably create some breaking changes with many canisters.
So really, I see no option other than moving forward with this proposal and removing the restriction. It really won’t change much (from what is currently technically possible) other than giving dev’s an easier time coding staking dApps on ICP (which I’m happy about).
I believe that the first part should have been implemented a long time ago, with functionality similar to how SNS neurons and their management are done. What about phase 2 and phase 3? Am I correct in understanding that the yield on neurons controlled via a canister will always be lower than neurons with PoK, or am I misunderstanding something? And the main question - why will Dfinity decide how I can manage my funds invested in the neuron. Why can’t I sell it, transfer it as an inheritance, or do something else if necessary?
To ensure we’re on the same page, I want to clarify that I’m not opposed to canisters controlling neurons. My objection is to the added complexity in calculating voting power and to the proposed solution that results in some neurons being more advantageous than others. Neurons should be considered equal if they have the same dissolve delay, stake, and age. I am firmly against any system where neurons created before a certain date or through a specific method, device, etc., are given an advantage.
In essence, we’re looking at multiple proposals bundled into one:
Canisters should have the option to control neurons. – I agree.
Neurons created with a ledger should be considered superior to those created with Internet Identity (II) or by a canister. – I strongly disagree.
Neurons created before a specific date should be given preferential treatment over those created after. – I strongly disagree
If neurons are transferable by design you break the fundamental “skin in the game” assumption of the NNS and we will need a new security model. By definition, you make (far) shorter-term decisions if there is an exit possibility before your unlock, even at a discount.
That’s why I think of this as a mid- or long-term strategy; it requires careful evaluation, but it shouldn’t be taboo, because it was initially made like this. And neurons or voting power are transferable. It’s just not secure, nor trustless, and has a lot of friction and workarounds.
Now we understand that it is possible for a canister to hold a neuron via a workaround. The proposal is to remove the workaround. And I assume someday we can remove the workaround of transferring/selling neurons as well and make the process secure and trustless.
But returning to the proposal:
On one hand, the proposal presents an improvement, such as enabling canister-controlled neurons, which paves the way for correctly implemented liquid staking and smart wallets (canister wallets) capable of holding staked ICP. However, the proposal immediately penalizes these initiatives with a 20% decrease in rewards. It just doesn’t make any sense.
Once again, this is just your opinion, unsupported by any evidence. Personally, I disagree. In fact, I did the opposite by staking for 8 years without dissolving, solely because there’s an opportunity to exit in case of extreme necessity. Without such an option, I probably wouldn’t have committed to a maximum stake. This is purely my opinion, too. Moreover, this stance does not compel me to make short-term decisions.
Looking at the recent voting chart, what do we actually see? I notice 10-15 significant rises, leading me to believe that up to 20 neurons with significant voting power either directly or through following, make decisions. There’s no decentralization. Today, 15! It may not be the case, but the opposite can’t be disproved due to the lack of transparency! And this issue of locking neurons from being transferred or sold is not addressed at all!
@bjoernek I’ve wanted this restriction lifted for a while now and I appreciate you putting this proposal forward. I’m not a fan of implementing a PoK just for the sake of distinguishing between a traditional private key and a threshold private key but I can accept that as our plan if it means we can move forward with lifting the restriction in the meantime.
I’m not requesting the disclosure of any private information about neuron owners. My focus is solely on the neuron IDs and their follow lists. What issues arise from making abstract IDs public, especially when they have no direct correlation to personal or private information?
I don’t think it needs evidence. It is math. It only takes one sub-optimal decision to make fully optimal never achievable. I’m happy to be convinced otherwise, and I admit that serendipity and luck likely play a long term role in where we end up but our network governance shouldn’t be based on “hopefully we get lucky”. We have to make the best possible long term choice for the network at every juncture with the info we have.
I don’t mean this in any mean or nasty way, but in a definitional way in game theory: you are an adversary to the network. Your stake is a false signal to the those that the network is secure. We do not want a network we’re you have an opportunity exit in any case. It is the only way to maintain the optimal prisoners dilemma result.
Network dynamics and the hurdles this network will face are extreme in their volatility and predictability. A small external occurrence can may your ‘extreme necessity’ the common rule.
Bluntly, we don’t want your maximum stake because your would consider exiting under some condition. Your stake is a drag on the network achieving its best longterm choice in each vote. In fact, your non-reliable stake steals maturity from others that won’t exit. There is a case that it is theft from the network and it’s securers.
I can give that in most expected instances you may feel this is true, but I’m worried about the ones you don’t expect. Any ability to exit provides a discount on the risk of a possible network action. Either we are all locked in the room together with a demand on solving a problem(the room is on fire) or there is a 10% chance that each can get out resulting in 10 lucky out of a hundred stealing life from the others when some number run for the exit instead of facing the network adversity.
I don’t follow the point here, can you clarify? Clearly we have a ways to go to optimal decentralization(if that is a thing when making decisions likely require expert knowledge).
I’m not opposed to more clarity here. I think there’s value in seeing where all the voting power flows. There may be some danger to no neurons, but I’d have to think about it for a little bit.
In this chart below, there are 10 main points that influenced the decision of this vote. It’s hard for me to imagine that tens of thousands of neurons currently in the network just randomly distributed themselves across these points. What I see is that these points are either neurons with a significant amount of weight or other neurons following them through the follow mechanism. And it looks on the chart as if just 10! “NEURONS” made the decision. There’s no even distribution of votes. Maybe I’m wrong, but we are lacking transparency.
After having gone through all the trouble to create a DAO-controlled neuron feature (using tECDSA signed HTTPS outcalls) for @Personal_DAO’s, I can testify that the cat is out of the bag with respect to canister controlled neurons. Especially considering that Personal DAOs are built to repeatedly deployed as standalone, commoditized applications. @skilesare I understand your reasoning for not wanting transferability of neurons, but its already available and will become widely available for the end user soon. And to make any attempts to remove that capability would have large negative consequences for the ecosystem now that so many projects have already incorporated canister-controlled neuron functionality into their codebase and business models.
The best thing to do to address the security concerns at this point would be to persuade stakers to stake via non-transferrable neurons via some incentive structure. a PoK neuron system in which PoK-compliant neurons are rewarded at higher rates than non-compliant neurons is the only recommendation I’ve heard thus far that provides that incentive structure. I’m open to hearing more though.
Ahh…I get it …yes. More transparency here would be great. Also, the ability to change your vote if you don’t like what your delegate did would be nice from a responsibility, regulatory, and “cooling the temperatures” of public debate.
It would let known neurons vote early and engage in debate, but would slow the execution of items as an absolute active majority would be required to execute early. This might need to be topic sensitive and maybe just apply to the newer “critical” proposals.
I’m not in any way against the canister control, I’m against transferability.
My suggestion is that this “penalty” for not having a PoK be waived for known neurons that dox themselves. Maybe they don’t even need to be known neurons in the NNS sense, but providing evidence that you are a canister controlled neuron and that the controller will not change(a change in controller would auto ban the neuron from this proposed dox list.)
If you are building a service where one controller has theoretically control over many neurons that people think they have staked securely, I’d say this is a massive security risk and should be a red flag to anyone using that service unless the controller is significantly decentralized and capitalized to avoid takeovers.(not saying this is the case with your service, but this config occurred to me and it seems worth mentioning)
It seems a bit strange that something like the OpenChat neuron would be penalized when we all know who it is and that it has a sufficient level of decentralization that reasonably guards against takeover.
I guess in theory I’d be in favor of a system that required either PoK or canister doxing with controller commitment.
Maybe even services like gitcoin passport could be used to ensure that it is very very difficult to transfer ownership.
Thank you for initiating this discussion, Bjoern. Here are my thoughts:
I support lifting restrictions on canister control over neurons.
However, I am unsure about the implementation of the remaining phases.
My main reasons are as follows:
The proposal seems complex, adding to what is already a complicated process for the average user.
I fail to see the risk in removing the restriction. But perhaps this is rooted in my belief that the majority of stakeholders possess the capacity to prioritize their long-term interests over short-term gains.
After reviewing all the comments, I’ve arrived at the following conclusion. PoK will only be necessary for new neurons to obtain the maximum reward, but it remains an OPTIONAL measure for users to apply PoK to old neurons as well. This implies that potentially PoK could apply to ALL neurons. Given that there’s no way to verify whether a neuron has PoK, we must assume that all neurons possess PoK. This effectively stifles the inception of any DeFi activities involving neurons. It will not be possible to collateralize, sell, or perform any actions with a neuron. It will merely lie dormant, serving only for voting purposes. This is a crucial point, and I want us all to understand the implications of this, not just the removal of restrictions in the first phase. As we know, DeFi is currently a sore point of the ecosystem, which is almost nonexistent, and DFINITY is losing out to other ecosystems in this regard. What little we have, we’re destroying and hindering further.
As I said before I strongly disagree on the Phase 2 and 3!
Canister controlled neurons have been requested by the eco-system for a long time and I see PoK as a solid option if it let’s us achieve this. What other solution would you propose?
Is your main problem that you can’t sell your neuron? If so, I think that is the point and it was never intended in the design to be able to sell neurons. I don’t see this as limiting DeFi in any way - I believe with canister controlled neurons we would see many new types of applications appear with really interesting use-cases.
The current way to sell neurons is by selling your internet identity? If releasing PoK gives us canister controlled neurons and removes the ability to sell neurons via internet identity - I think the final outcome would be more steadfast voters and new DeFi staking applications (obviously that’s just an assumption based on the proposed solution).
