#1 Improve staker P/L by (1) increasing period duration & (2) editing min. stake size

TLDR

  • Running a NuCypher worker is too expensive, particularly for independent operators.
  • Existing mitigations (e.g. gas price ceiling) are potentially service disrupting and wealth concentrating.
  • Lowering worker overheads enables more competitive break-even price points (min fee rate) – likely to hasten/widen adoption.
  • We propose two solutions in concert: (1) increase the global period duration parameter (currently 24h), and (2) change the minimum number of tokens required to create a new sub-stake (note that existing sub-stakes will be unaffected).
  • This proposal will require a proactive and (somewhat) synchronous migration of stakers from the current to upgraded protocol.
  • Solution (1) reduces the cumulative gas costs necessary for worker availability commitments and reward minting over time, and solution (2) increases the likelihood of new sub-stakes being economically sustainable.
  • Community feedback on this proposal is essential, particularly for the new period duration parameter (e.g. 1 → 5 days). Signal your preference at the bottom of this post!

Context & Existing Mitigations

Today, NuCypher stakers confirm their availability for the forthcoming 24-hour period via the commitToNextPeriod() function, which also prompts the execution of the subsidy-generating mint() function for the previously committed-to period. Overall, this daily check-in requires between 200k and 800k in gas, largely depending on the number of sub-stakes they control. Approximately half of this gas is spent on accounting; necessary calculations to mint subsidies. Each sub-stake’s size is verified on a daily basis, then the remaining duration until it unlocks, the re-staking flag, and other permutations (such as missing previous commits) are all taken into account to generate a NU-denominated reward figure for that period. These functions are exceptionally efficient given the variability of inputs, corner cases and considerable economic harm that would be caused by erroneous calculations.

Reducing these gas costs has been a hot topic for some time, with possible remedies raised in the run-up to network launch, and since then, smaller operators voicing their concerns with growing regularity. Despite this, no proposals or ideas have been submitted to the DAO forum that might wholeheartedly address the problem. There have been mitigations; including an upgrade enabling inactive sub-stake removal (the first smart contract upgrade validated by the DAO), and more recently, the introduction of client-side powers to specify a hard ceiling on the gas price a worker may commit with. The latter arrived just in time for stakers to weather a winter of perennially elevated gas prices – preventing the hemorrhaging of ETH, but at the expense of NU rewards. This can lead to long-term problems –> see this issue for more.

A reduction in NuCypher’s active worker population over past months, utilizing the gas price ceiling feature, is in one sense relieving to the protocol designer; it’s evidence of highly rational and economically conservative decision-making. Unlike service-side participation based on overexcitement or speculative finger-crossing, which are fickle, the behavior of NuCypher stakers suggests that a long-term, robust solution to excessive overheads will prompt worker reactivations with long-term, robust commitment.

Long-term sustainability of stakers and the network

This section delves into adopter-centric and service pricing based arguments for reducing worker overheads. If you’re already convinced, skip to the next section.

An appropriate pricing structure is critical for growing and retaining a user base, sustaining the staker population, and upholding the service’s value propositions – scalability, redundancy, censorship-resistance, and extensibility. The primary trade-off is between (1) affordability for as broad a spectrum of customers as possible and (2) sustainability of a large and diverse staker population. For the dynamic access control (proxy re-encryption) product, this relationship can be expressed as follows:

Break-even number of users =
(Annual worker operation cost * Number of Stakers) /
(Daily policy fee rate * Mean policies created per user annually * Mean. policy duration in days)

This formula oversimplifies reality – for example, it assumes that all NuCypher stakers have equally sized stakes. Nonetheless, it’s quite clear that the greater the annual cost of running a worker (in the numerator), the greater the user base required for stakers to break even on fees alone, and the longer it will take us get there.

Even with a somewhat blurry view of prospective adopter budgets, it is almost guaranteed that lowering the daily policy fee rate would broaden the network’s addressable markets. The more domains in which the service is affordable, and therefore viable, the sooner the network can reach meaningful traction. For (much) more detail on NuCypher’s pricing strategy, see the pricing whitepaper.

A lack of sustainability for certain stakers poses other threats to adoption. Operating at a loss (without reward-based subsidization) carries the prospect of price hikes in the future. This inhibits integration today – many use cases are only viable within a strict fee range. The developers of a decentralized Netflix or Wikileaks are presumably in it for the long run, and will do their homework before choosing infrastructure. Put simply, the network must appear economically viable post-subsidies.

There are further advantages to affordable worker operation. Stakers located in a wide variety of economic/social circumstances confer the network a geographical resilience – collusion attacks are far more difficult to orchestrate. Less obviously, the network also gains greater economic resilience. A healthy pool of shallower-pocketed stakers boosts NuCypher’s power to survive eras of lower revenue – whether this is due to the whims of the market or the customer. Revenue which would be less significant to larger stakers, may be worthwhile to those with lower alternative income – thereby supporting the service’s persistence.

Last but not least, accessible service-side participation aligns strongly with NuCypher’s ethos and brand. We’re backing decentralization, democratization, openness, economic empowerment and cooperative ambition.

Solution 1 – Extending the period duration

This upgrade will extend the minimum unit of availability commitment by workers. It would also extend the minimum duration of a sharing policy by the same multiple. Workers will need to check in and spend the corresponding gas less frequently, and users will have to choose policy durations with less granularity. The issuance (reward) schedule would not change as part of this upgrade with respect to time. For example, a period extension to 5 days would mean that, compared to the status quo, stakers would receive 5x the number of tokens each time they commit (and mint rewards), such that the aggregate earnable subsidy in a given year remains the same, minus rounding adjustments.

Advantages

  1. Unlike alternative solutions, extending the period globally does not require a total rethink of the protocol architecture. The required changes are mostly contained to the StakingEscrow smart contract (StakingEscrow.sol) and the economics configuration settings (Economics.py). Except for the parameter adjustments, these changes have already been implemented, and are ready for an external audit this week (w/c 02.22.21).
  2. An extended period will reduce the cumulative gas expenditure of both the commitToNextPeriod and mint operations, by whatever extension multiple is selected. Executing these two functions account for the lion’s share of worker gas overheads.
  3. Over time, this approach significantly decreases the cost of staking in absolute terms. These savings will constitute a greater percentage of independent operators’ budgets, disproportionately favoring shallower-pocketed stakers and combatting wealth concentration dynamics.

Disadvantages and mitigations

  1. Editing the global temporal unit of the network will require an active and synchronous migration of stakers from the current protocol to the new one. The actions required to migrate are likely to be straightforward, but laggards will miss out on subsidies and could face bigger issues if they wait too long.
  2. This upgrade may inhibit use cases in which the typical frequency of policy creation is high – there is extra expenditure in aggregate if the minimum unit for policy duration is less granular.
    However, the indirect price-based benefits conferred to adopters via cheaper worker operation (see arguments above) outweigh the rounding costs of longer policies. Moreover, certain use cases will face this issue with the current minimum policy duration (24h), rendering usage of NuCypher unfeasible as it stands. For example, a connected vehicle communicating with other cars whilst on the road may need policies that expire in minutes, and/or charge far less than current min fee rates. Finally, tweaking the logic of the revocation command may help here – specifically, to ensure users who only use a small percentage of a multi-day day policy receive a pro rata refund if they revoke early.
  3. Infrequent check-ins may enfeeble honest (non-adversarial) stakers. For example, waiting longer to fix worker technical issues, given the extra time until the next on-chain interaction. Lowering gas costs also decreases the cost of checking in as a percentage of total operational costs, which implies greater relative savings in eschewing other worker duties.
    However, the minuscule savings of being offline (in between commits) are outweighed by damage to the network’s reputation if many users endure an unreliable service. This may depreciate the native token’s value – in which the bulk of staker assets and income are denominated. Moreover, delegating (unlocked) NU tokens to a pool may be preferable to setting up a ‘commitment bot’ – given the requisite effort, gas costs, and risks of being slashed in a later version of NuCypher that monitors and punishes downtime. Indeed, the NuCypher DAO can impose slashing penalties for non-availability if necessary.
  4. Stakers will have to wait longer to receive their first payout, since two periods must be successfully completed before rewards are issued.

Parametrization & other considerations

1. New period duration
Please signal your preference (max 2 choices) via this informal poll.
The greater the new duration, the greater the consequent reduction in worker overheads.

New period duration
  • 2 days
  • 3 days
  • 4 days
  • 5 days
  • 6 days
  • 7 days
  • 8 days
  • 9 days
  • 10 days

0 voters

2. Sub-stake lock-up duration rounding
All sub-stake lock times will have to be expressed as a multiple of the new period duration. Hence at the moment of staker migration, lock times must be rounded up or down. It would be generally more advantageous to round down, such that stakes unlock sooner rather than later. This will be the default approach unless the community provides compelling reasons to round up.

3. Cancellation of policies
There is no easy way to port policies over to the new protocol, so all existing sharing policies will be discontinued and refunded before the migration may occur.

Note – post to follow on solution 2: new minimum sub-stake size.

1 Like

Assuming some future Layer 2 solution, would it be possible to easily revert to daily commitments in the future?

1 Like

Yes - it is possible to change period duration again by performing the same period recalculation with a new value, followed by another DAO proposal and contract upgrade. The migration code introduced in https://github.com/nucypher/nucypher/pull/2549 can be applied using the new values.

1 Like

I would love to hear people’s rationale for periods that aren’t 7 days. What are benefits of say… 6 days?

7 days period duration parameter sounds great. it will wake up a lot of smaller nodes!

Saturday and Sunday are the best for confirm period TXs!

1 Like

7 day periods have the benefit of being human-grokkable and easily accommodating a monitoring or commitment strategy constructed around a weekly cadence.

I’m really happy to see this being worked on - I think it will make node running a significantly more approachable and sustainable practice. In general, I’m in favor of longer periods, ten days seems great, though it looks like the majority is pulling for 7.

1 Like

Yes, I can see this happening. Though I think the scenario in which that is most worthwhile is the following:

  • There is tangible evidence that 7-day policies are impeding adoption – i.e. vetted customers with strong fee generation potential demand this change in no uncertain terms.
  • We can substantiate (game-theoretically or empirically) the hypothesis that more frequent check-ins increase overall fleet availability/reliability.
  • We achieve a gas cost saving multiple of at least 1000x via the L2 scaling solution. See https://github.com/nucypher/productdev/issues/17#issuecomment-781790649

support 7 days, nice proposal

super, proposal, as a small node staker, this is a total game changer for me

I think these points are not to be underestimated. We want NuCypher network to stretch far and wide.

Thanks @arj for this.

1 Like

Honest question, is it not possible to move to an EVM compatible blockchain having faster finality and lower costs?

Honest question, is it not possible to move to an EVM compatible blockchain having faster finality and lower costs?

This avenue is being examined independently of the results of this proposal.

1 Like

I’m not sure of its feasibility, but a period duration variable that is user-assignable within a somewhat narrow window, e.g., 7 - 10 days, could create a variable spread of period confirmations that is continually changing - might have some nice effects re reducing network spikes or something along those lines. could be infeasible technically, just an idea. unless being able to predict X number of period confirmations on wednesday’s or thursdays is ideal.

This feels like the right move at this early stage of the network’s evolution. I say this based solely on the need #1 right now, as gas fees have taken many smaller operators out of the game.

It’s not clear to me how #2 -

And I would like to understand more about this.

I also noticed this comment.

Does this mean the “absence” of 7-day policies is impeding adoption or that the “potential of adopting” 7-day policies is impeding adoption?

Regardless, I still support this proposal. I believe it will help set a strong foundation for the network to service policies among a diverse set of operators, big and small.

My sense is that the priority is establishing a strong foundation from which to service policies. Hopefully adoption follows once the stable foundation is in place. Assuming it does, a stable foundation will increase the likelihood that early adopters are served well by the network.

1 Like

in my opinion, while maintaining the current size of the sub-steak, adding new ones can be from 100k, but it may make sense to increase in stages, for example, double monthly

I meant that in the future, if/when the minimum duration unit for a sharing policy is 7 days, there may be evidence that this system constraint makes usage of the network unaffordable for certain use cases. If, by then, a L2 scaling solution has been successfully integrated with, say, a 100x or 1000x cost saving, it may be worth reducing the period/policy duration to accommodate those prospective adopters.

With respect to min. stake size – the greater the relative size of a given stake, the greater the sum rewards it is eligible to receive, thereby improving the owner of that stake’s P/L, since outgoings are a (semi-)fixed absolute figure. Of course this only works if, relative to the status quo, a smaller number of stakers are willing/able to fulfill the new min. stake requirements – otherwise, ceteris paribus, the rewards wouldn’t change. In any case, this component of the proposal is looking increasingly unnecessary given the upswing in (fiat) costs of creating a new sub-stake from scratch.