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
- 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).
- 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.
- 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
- 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.
- 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. - 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. - 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.
- 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.